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(54) Session initiation protocol (SIP) user agent in a serving GPRS support node (SGSN) 



(57) A Session Initiation Protocol (SIP) application 
server (216) is connected to an SGSN (208) by a SIP 
user agent (214). The SIP user agent (21 4) supports the 
SIP protocol. The system is implemented using a GPRS 
Attach/Detach state model and a GPRS PDP context 
state model. When relevant detection points in these 
state models are encountered, the SGSN (208) pro- 



vides an indication to the SIP User agent (214), which 
will detenntnethe necessary action, i.e., trigger the net- 
work event to the SIP application sen/er (216), where 
service logk: is invoked and executed. SGSN (208) re- 
quested PDP context activation capability is added in 
order to support push services from the SIP application 
service. Operator owned PDP context is added in order 
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Description 

[0001] The present Invention relates to teleconDmuni- 
cation systems and, particularly, to a system for imple- 
menting a Session Initiation Protocol (SIP) User Agent s 
in a Serving GPRS Support Node (SGSN) in a General 
Packet Radio System (GPRS). 

[0002] GPRS is a data service for GSM (Global Sys- 
tem for Mobile Communication) networks. GPRS ts a 
packet-based technology that allows an end-user to re- io 
main constantly connected and to send and receive data 
at speeds higher than those available for prior circuit- 
switched technologies. 

[0003] A simplified diagram of a basic GPRS system 
is shown in FIG. 1. The system 100 Includes, a mobile is 
station 102, whkrh may be, for example, a notebook 
computer with a GPRS-capable PC card. The mobile 
statk>n 102 communicates with a Base Station System 
(BBS), i.e., GSM Base Station System or Universal Mo- 
bile Telecommunk:ations System (UMTS) Terrestrial 20 
Radio Access Network (UTRAN) 104. The base station 
system 104 sends and receives GPRS packets to and 
from the GPRS network 1 06. In partk:ular, the base sta- 
tion system 104 sends and receives the GPRS packets 
to and from a Sen/ing GPRS Support Node (SGSN) 1 08. 2S 
The SGSN 108 monitors the mobile statk>ns within its 
sendee area and Interfaces to the mobile stations 1 02. 
The SGSN 108 communk:ates with a Gateway GPRS 
Support Node (GGSN) 110 via a protocol called the 
GPRS tunnel protocol (GTP). TheGGSN 110 Interfaces 30 
to packet data networks (PDN) 112, such as Internet or 
X.25 networks. When the nnobile station 102 sends data, 
the packets are sent via the SGSN 108 to the GGSN 
110, whch converts them into the desired fomiat. Pack- 
ets from the PDN 112 are received at the GGSN 110, 35 
then fonwarded to the mobile station 102 via the SGSN 
108. A Home Location Register (HLR) 114 stores vari- 
ous subscription information. 

[0004] The GPRS network provides a data rate of 
over 100 kbps. The data rate would be tripled to up to 40 
384 kbps if the GPRS networic is enhanced with EDGE 
(Enhance Data rate for GSM Evolution) technology. 
UMTS will further increase the data rate to up to 2 Mbps. 
The high data rate makes it possible for a mobile user 
to access to data and multimedia content. GPRS how- ^5 
ever, does not itself define when and how that content 
is delivered. 

[0005] The invention is defined in the independent ^ 
claims, to which reference should now be made. Pre- 
ferred features are set out in the dependent claims. so 
[0006] According to one embodiment of the invention, 
a Session Initiation Protocol (SIP) application server is 
connected to an SGSN/gprsSSF by a SIP User Agent 
(UA). The SIP UA supports the SIP protocol. The system 
is implemented by reusing a GPRS Attach/Detach Finite 55 
State Model and a GPRS POP Finite State Model. When 
relevant detection points In these state models are en- 
countered, the SGSN provides an indication to the SIP 



2 

User Agent, whk:h wilt determine the necessary action, 
i.e., trigger the network event to the SIP Application 
Server with SIP request. 

[0007] According to one ennbodiment of the invention , 
the GPRS system supports both SIP Applk:ation Server 
(SIP AS) and CAMEL Servce Environment (CSE). In 
operation, the system detemiines if a mobile station is 
to be provided a CAMEL-triggered or a SIP-triggered 
servk:e, based upon 5ut>scrtption infomiatbn stored in 
an HLR or the SGSN configuration. The system then 
allows the appropriate service to be invoked and exe- 
cuted. 

[0008] A system according to another embodiment of 
the present invention innplements operator-owned PDP 
contexts used for operator-initiated servfces. Such a 
PDP context activation is triggered by a network event, 
such as a GPRS network event or a servkre network 
event. In a typk^al case, session nrtanagement (SM) re- 
ceives an instruction from a furK:tk>nal entity triggered 
at the network event and starts the procedure to activate 
the operator owned PDP context. The GGSN 210 as- 
signs a PDP address, whk:h is an IP address, to the PDP 
context and sends the address to an applicatk>n plat- 
form so that multimedia contents can be pushed to the 
con^esponding IP address. 

[0009] A better understanding of the invention is ob- 
tained when the folkwing detailed description of embod- 
iments thereof is considered in con]urK:tion with the fol- 
lowing drawings in whk:h: 

FIG. 1 is a sinnplrfied diagram illustrating GPRS net- 
work system: 

FIG. 2 Is a diagram Illustrating a GPRS-SIP networic 
according to an implementation of the invention; 
FIG. 3 illustrates the control plane with SIP Appli- 
cation Server according to an ennbodiment of the 
present invention; 

FIG. 4 is a block diagram of a SIP applk:atk)n server 
according to an embodiment of the present inven- 
tion; 

FIG. 5 illustrates an Attach process according to an 

implementation of the invention; 

FIG. 6 illustrates PDP context activatton according 

to an implementation of the invention; 

FIG: 7 illustrates detection points the invention will 

reuse; 

FIG. 8 illustrates a GPRS Attach/Detach finite state 
model (FSM) the invention will reuse; 
FIG. 9 illustrates a PDP context finite state model 
(FSM) the invention will reuse; 
FIG. 10 illustrates SGSN Requested PDP Context 
Activation according to an implementation of the in- 
vention; 

FIG. 11 Illustrates operation of a SIP application 

server as a PUSH originator; 

FIG. 12 illustrates the SIP application server as a 

Presence server; 

FIG. 13 illustrates push web-based pre-paid re- 
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charging; 

FIG: 14 illustrates an exemplary SGSN according 
to an embodiment of the present invention; 
FIG. 1 5 is a flowchart illustrating operation of an em- 
bodiment of the present invention; and s 
FIG. 1 6 is a flowchart illustrating operation of anoth- 
er embodiment of the present invention. 

[0010] F\GS. 2-16 illustrate a system and method for 
providing multimedia content in a GPRS network ac- io 
cording to an implementation of the invention. 
[0011] A diagram of an exemplary GPRS-SIP system 
according to an implementation of the invention is 
shown in FIG. 2. The system 200 includes a mobile sta- 
tion 202, which may be, for example, a notebook com- '5 
puter with a GPRS-capable PC card. The mobile station 
202 communicates with a Base Station System (BSS), 
i.e, GSM Base Statk>n System or UMTS Terrestrial Ra- 
dio Access Network (irTRAN) 204. The base station 
system 204 sends and receives GPRS packets to and 20 
from the GPRS network 206. In partk;ular. the base sta- 
tion system 204 sends and receives the GPRS packets 
to and from a Serving GPRS Support Node (SGSN) 208. 
The SGSN 208 rTH>nltORS the mobile stations within its 
service area and Interfaces to the mobile stations 202. 
The SGSN 208 communk:ates with a Gateway GPFIS 
Support Node (GGSN) 210 via a protocol called the 
GPRS tunnel protocol (GTP). The GTP protocol is over 
UDP/IP protocols. The GGSN 210 interfaces to packet 
data networks (PDN) 21 2, such as Intemet or X.25 net- 30 
works. When the mobile station 202 sends data, the 
packets are sent via the SGSN 208 to the GGSN 210, 
whrch converts them into the desired format. Packets 
from the PDN 212 are received at the GGSN 210 then 
forwarded to the mobile statk>n 202 via the SGSN 208. 35 
An HLR 215 is provided for subscription informatk>n. In 
addition, the GGSN 210 may communicate with the SIP 
AS (appfcation server) 216 via an Intranet or the Inter- 
net (not shown). 

[0012] The SGSN 208 further includes an SIP User ^ 
Agent (SIP UA) 214. The SIP user agent 214 commu- 
nicates via the Session Initiation Protocol with a SIP Ap- 
plication Sen/er (SIP AS) 216, as will be discussed in 
greater detail below. Thus, the GPRS 206 supports the 
multimedia services triggered with SIP requests. More 
particularly, in the appropriate point in mobile station 
processing, the SIP user agent 21 4 is activated to inter- 
act with the SIP application server 216 to provide mul- 
timedia services to the mobile station. 
[0013] The SIP application server 216 can co-exist 50 
with a standard (Customized Applicattons for Mobile 
network Enhanced Logic) service environment (CSE) 
220. The CAMEL service environment allows the GPRS 
network to support services otherwise not supported by 
GSM, such as Prepaid service. However, CAMEL does 55 
not support multimedia services. As will be described in 
greater detail below, according to one implementation 
of the invention, the SGSN 208 detemnines if a network 



event to be triggered to the CSE 220 or to the SIP AS 
216. 

SIP Application Server 

[0014] The SIP application server control plane is 
shown in FIG. 3. The SIP protocol is used to transfer 
signaling messages between the SGSN 208 and the 
SIP applk^ation server 21 6. The SIP user agent (UA) 21 4 

sends SIP requests to a SIP AS 216, processes the re- 
sponses and interacts with other functional entities in 
the SGSN 208. 

[001 5] As will be explained in greater detail below, the 
SIP applk:ation server 216 is a SlP-based servbe plat- 
form, i.e., may be implemented as a SIP proxy/redirect/ 
registrar server enhanced with service logic execution 
environnr>ent, APIs, web server, and media servers. The 
web server in the SIP AS 216 provkies SIP session 
event triggered web servk:es/applk:atk>ns, as welt as 
HTTP event triggered SIP sessu>n sen^k^e such as clck- 
to-dial. A media server can be an E-mail server or Short 
Message Servk^e Center, etc. The media servers may 
not necessarily reskie in the same box as the SIP AS 
216. A media sen^r provides SIP session event trig- 
gered multimedia servk:es, or vk:e versa, media trig- 
gered SIP ses5k>n servces. 

[0016] More particularly, FIG. 4 is a diagram illustrat- 
ing an exemplary SIP application server 216 in accord- 
ance with an emtx>diment of the present irtvention. The 
SIP Applk:ation Server 216 is a servk^e centric SIP 
Proxy/Redirect/Registrar Server to provide vok:e/web/ 
email combined multimedia servk^es. In the embodi- 
ment illustrated, the SIP Application Server 21 6 includes 
a Call Server 1100. a Web Server 1 1 02, a Media Server 
1104, and an Executk>n Environment 1106. IT^ Media 
Server 1104 may not necessarily be an integral part of 
a SIP Applk:ation Server. In certain embodiments, the 
SIP Applk3tion Server 216 is able to interface v^th ex- 
ternal Media Servers (not shown) via IETF protocols 
whether it has intemal Media Servers or not. 
[001 7] At the center of the SI P Applk:ation Server 216 
is the Execution Environment 1106. The Execution En- 
vironment 1 1 06 may be any set of software, for example, 
that deddes how to execute SIP scripts. The Execution 
Environment 1 1 06 receives a request from a Call Server 
1100, or Web Server 1102. or Media Server 1104, and 
maps the incoming request to the corresponding servk^e 
logic, and then retrieves the servbe logic and hands it 
to the corresponding API 11 1 0 for interpretation or exe- 
cution. The sen/ice logk: may call the functionality pro- 
vided by the Call Server 1100, or Web Server 1102 or 
Media Sen/er 1104 to generate SIP/HTTP/SMTP re- 
quests or responses. 

[0018] In certain embodiments, the SIP application 
server 216 supports Session Initiation Protocol (SIP), 
Hypertext Transfer Protocol (HTTP), Simple Mail Trans- 
fer Protocol (SMTP), etc. The SIP application server216 
may support other protocois depending on what other 
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media capabilities are desired, and what side channels 
are required to communication with other application 
servers. 

[0019] As a SIP Proxy/Redirect/Registrar Server, the 
SIP Application Server 216 supports the SIP protocol to t 
handle SIP requests and responses. In addition, It may 
support various service/application-oriented extensions 
to the baseline SIP. One is SIP extension of SIMPLE 
(SIP for Instant Messaging and Presence Leveraging) 
in order to support Preser)ce and Instant Messaging n 
services, as will be explained In greater detail below. 
[0020] The Call Server 1100 is a SIP protocol engine 
that processes SIP requests and responses. The Call 
Server 1100 may support service/application-oriented 
extensions to the baseline SIP. Among these are the 
SUBSCRIBE and NOTIFY messages as specified in 
SIMPLE, which are used to implement Presence and 
other services/applications needed to dynamically arm 
and report a trigger event. The Call Server 1100 inter- 
works closely with the Execution Environment 1 1 06, for 20 
example, in the same SIP Application Server In typical 
cases, the Call Server 1100 would hand the incoming 
SIP message to the Execution Environment 1106 for 
service/application execution decision. The Execution 
Environment 1 1 06 would then pass the possibly altered 25 
SIP message, controlled by service logic, back to the 
Call Server 1 1 00 for further processing in the same way 
as an ordinary SIP Proxy/Redirect/Registrar Server. 
The Execution Environment 1106, controlled by service 
logk:. may instruct the Call Server 1100 to generate a 30 
new SIP message within the current SIP sessk>n or to 
start a new SIP session. In the case of a new SIP ses- 
sion, the triggering event may either come from the Call 
Server 1100 or from the Web Server 1102 in response 
to an incoming HTTP request, or from the Media Server. 35 
1104. 

[0021] The Web Server 1102 provides web servk:e 
capat>itities and thus a convenient interface to the nno- 
bile subscribers, and also provides them with links to 
other multi-media services/applications URls (Uniform 40 
Resource Identifiers) in the PDN. There are several 
ways to use the Web Server 1 1 02 in the SIP Applk:ation 
Server environment. In certain embodiments, the Web 
Sen/er 11 02 is able to dynamically generate a web page 
as instructed by the Execution Environment 1106 as a ^5 
result of the execution of the service logic. The Web 
Server 1102 is able to return the generated web page, 
or the URL (Uniform Resource Locator) of the web page, 
to the Execution Environment 11 06 to be inserted Into a 
SIP message/response body, which supports Multlpur- 50 
pose Internet Mail Extension (MIME). The web page will 
then hftch hike in the SIP message to Its destination, 
possibly a mobile subscriber's device, and be rendered 
there. The Web Server 1102 is also able to "push" the 
generated web page, through its data network connec- 55 
tion, to a URL extracted by the Execution Environment 
1106 from header of the incoming SIP message handed 
over from the Call Server. This functionality can be used 



to realize the push portal servk:e. and other push serv- 
tces. The other way to use the Web Server 1102 is to 
use it the same way as an ordinary pull web server. How- 
ever, the processing of the incoming HTTP request is 
> also forwarded to the Execution Environment 1106 for 
further servk:e/application execution. The result could 
be used as a triggering event for a new SIP Session, 
which the Execution Environment 1106 would instruct 
the Call Server 1100 to carry on. Such servces include 
' 3rd party call control, clk:k-to-dial, etc. 

[0022] The SIP Application Server is usually equipped 
with a Media Server 1104 to provide multi-media serv- 
ces. Such multi-media services may include email, in- 
stant messagtr^g, audioA^ideo conferencing, unified 
' messaging, voice activated/controlled servfces, short 
message servk:e (SMS), etc. The SIP Application Serv- 
er 216 may interface extemal Media Servers via IETF 
protocols. The Media Server 1104 empowers a SIP Ap- 
plk:ation Server 216 with the capability to provkie voice/ 
web^ennail combined mufti-media servk:es. 
[0023] The Execution Environment 1 1 06 is the central 
part of a SIP Apptotion Server that interconnects all 
the other components. The Execution Environment 
1106 communicates with the Call Server 1100, the Web 
Server 1102 and the Media Servers 1104. In addition, 
the Executk>n Environment 1106 retrieves the servk» 
logic of the applk:atk>ns and executes the servk^e logk: 
through appropriate APIs 1110. 

[0024] When an incoming SIP request enters the SIP 
Applk:atk>n Server 21 6, it is received and handled by the 
Call Server 1 1 00. The Call Server 1 1 00 would then hand 

the SIP message to the Execution Errvironment 11 06 for 
service/application execution. The Execution Environ- 
ment 1106 invokes a mapping function (not shown) to 
map the SIP request to its corresporiding servce logk: 
1108 (application). The Executk>n Environment 1 1 06 re- 
trieves the servkre \ogk: 1 1 08. It then analyzes the serv- 
IcB logk: 1108 and finds out whk:h API 1110 supports 
this service logic 1108 and then hands the servk:e logic 
1108 to the appropriate API 1110 for interpretation or 
execution. The service logic 1108 may interact with the 
Call Server, Web Server and/or Media Server via the 
API 1110. 

[0025] When processing an incoming HTTP or other 
non-SIP message, the Web Server 1 1 02 and the Media 
Server 1104 have their own mapping functions to map 
the incoming request to the con^esponding servk:e logk; 
1108, for example, in the form of CGI and/or Servlets 
scripts, and then Interpret or execute the script via the 
appropriate AlP 1110. SIP-enabled APIs 1110 are used 
to Interact with the Call Server. 

[0026] The Execution Environment 1106 supports 
one or more SIP-enabled APIs 1110 such as Call 

Processing Language (CPL), SIP Common Gateway In- 
terface (SIP CGI), SIP Servlets and JAIN SIP, among 
others. New APIs can be loaded whenever it is needed. 

The Execution Environment 1106 retrieves the service 
logic 1108, analyzes the script, and hands it over to the 
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appropriate AP1 1 1 1 0 for interpretation or execution. The 
APIs 1110 support the functionality to interact with Call 
Server, Web Server and Media Servers. 
[0027] The applications 1108 (senfice logic) are de- 
veloped offline in a Service Creation Environment 
(SCE). After being tested, they are uploaded to the SIP 
Application Server 21 6. An application Is stored in the 
database as service logic in the Si P Application Server. 
The service logic can be uploaded, activated, deactivat- 
ed, or even replaced via, for example, via an OAM GUI 
interface. Applications 1108 are written in script lan- 
guages supported by the APIs 1110. 

ATTACH Operation and PDF Contexts Activation 

[0028] As will be described in greater detail below, in 
operation, a mobile station 202 must first -attach" to the 
GPRS network and then have the appropriate PDP 
(packet data protocol) contexts activated t>efore it can 
use network resources. 

[0029] An exemplary Attach process is illustrated in 
FIG. 5. In step 300, a mobile station 202 transmits an 
attach request to the new SGSN. In step 302, the new 
SGSN sends an kientification request to the old SGSN, 
whk:h responds with the Identification Response and 
the IMSI (International Mobile Subscrit>er Identity). In 
step 304, the new SGSN then sends an identity request 
to the mobile station 202 which responds with its identity. 
An authentk:ation is then performed in step 306. In step 
308; the new SGSN sends an update kicatlon to the 
HLR 215; the HLR 215 and okJ SGSN cancel the old 
location; the new subscriber data is inserted and the lo> 
cation Is updated. In step 31 0, a VLR (Visitors Location 
Register) is updated. In particular, the new VLR sends 
the update information to the HLR 215, which cancels, 
the old k>catk>n with the old VLR. The new subscriber 
data is then Inserted. In 312, the SIP interaction may be 
performed to establish the SIP sessk>n. Essentially, the 
mobile station 202 and the SGSN undertake an ex- 
change acknowledging the presence attempt of the mo- 
bile station and that it is reported with a SIP request. In 
step 314, the attachment to the GPRS network is com- 
pleted. Finally in 316, a SIP interaction may be per- 
fomned again to establish the SIP session. The mobile 
station 202 and the SGSN 208 undertake an exchange 
acknowledging the presence completion of the mobile 
station and that it is reported with a SIP request. Upon 
initial attachment, whether the attach event is reported 
with CAMEL via gprsSSR which may interact with the 
CSE in 312, or with SIP via SIP User Agent, which may 
interact with the SIP AS in either 312 or 316 or both, is 
decided based on the subscription Information provided 
through the HLR 215, or the SGSN configuration. 
[0030] FIG. 6 illustrates the MS-requested PDP con- 
text activation procedure according to an implementa- 
tion of the invention. In step 402, a MS 202 sends a PDP 
Context activation request message to the SGSN 208. 
The message contains information such as PDP type, 
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PDP address, access point name, QoS requested, and 
the like. In 404, a SIP-GPRS-Actrvate-PDP-Gontext trig- 
ger anmed at PDP Context Establishment DP occurs. 
Briefly, the PDP context activatk>n attempt with any nec- 
essary mobile station capability and address informa- 
tion may be provided using the SIP protocol. In step 406, 
security functions may be Implemented. In step 408, 
SGSN 208 invokes a trace to BSS 204. In step 410, SG- 
SN 208 sends a Create PDP Context Request message 
to the affected GGSN 21 0; once created, the GGSN 21 0 
responds to the SGSN 208. In step 412, packet flow con- 
text procedures may be executed. In 414, the 
SIP-GPRS-SGSN-Create_PDP_Context trigger armed 
at PDP Context Establishment Acknowledgement DP 
occurs, reporting using SIP protocol the requested SIP 
PDP context is established. In step 416, the mobile sta- 
tion is notified that the PDP context actlvatk>n is accept- 
ed. Whether the PDP context activation events should 
be reported in 404 and 414 respecthrely with CAM EL via 
gprsSSF or with SIP via SIP User Agent is decided 
based on the subscription information provided through 
the HLR 215, or the SGSN configuration. 
[0031] GPRS supports multiple PDP (packet data 
protocols) contexts simultaneously for an attached sub- 
scriber. Thus, the behavbr of a GPRS session is mo6- 
eted using two finite state models: one for attach/detach 
procedures and the other for modeling individual PDP 
context. As will be described in greater detail below, the 
GPRS state models identify points when operator spe- 
cifk: servk:e (OSS) k>gk: instances accessed via the 
CSE 220 are pemiitted to interact with bask: GPFIS con- 
trol capat>ilities. 

[0032] According to one embodiment of the invention, 
tiiese state models are reused to identify points when 
service k>gic instances accessed via. the SIP AS are per- 
mitted to interact with bask; GPRS control capabilities. 
[0033] In partk:ular, as shown in FIG. 7, components 
of such state models include transitk>ns 602, detection 
points (DP) 604, and points in association (PIA) 606. 
The detection points 604 are points in processing at 
which notifk:ation to the servk:e k>gic can occur and 
transfer of control to such logic is possible. The PIAs 
606 identify SGSN activities associated with the service 
logic instances. 

[0034] FIG. 8 illustrates the GPRS Attach/Detach 
FSM used to model the behavior of the GPRS attach/ 
detach procedures according to an Implementation of 
the Invention. As seen, the Attach/Detach FSM includes 
states Detached 706a. Attached 706b, and a transit 
state AD_Exception 707. Three detection points De- 
tached 704a, Attach 704b, and Change of Position 704c 
are shown. Finally, transitions 702a-d are provided. 
[0035] When one of the detection points 704a-704c is 
encountered, the SGSN will suspend normal processing 
and indicate the detection point to the gprsSSF (service 
switching function) for CAMEL treatment or SIP User 
Agent 216 for SIP treatment. The gprsSSF or SIP UA 
will determine the necessary action, and trigger the net- 
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work events to the CSE 220 or to the SIP AS 216 (FIG. 
2), where appropriate service logic is invoked and exe- 
cuted. With CAMEL approach, the DP Attach detection 
point 704b indicates that a request to attach has been 
received. With SIP approach, the DP Attach detection 
point 704b may alternatively indicate that the attach re- 
quest has been successful (but the Attach process is 
not completed yet). The DP change of position detection 
point 704c indk^ates that a routing area update has been 
accepted, and the DP Detached detection point 706a 
indicates that a detach request has been received either 
from the mobile station or the network. 
[0036] Zero or nnore PDP Context finite state models 
are associated with the Attach/Detach FSM when the 
latter Is in the Attached state. Such a context finite state 
model is illustrated in FIG. 9. Shown are Idle state 802, 
PDP_context_setup state 804, C_exception state 806, 
PDP_Context_Established state 808. and change of po- 
sition context state 81 0. Also shown are detection points 
PDP context establishment 820. PDP context discon- 
nection 822, PDP context establishnr>ent acknowledge 
824, and change of position context 828. When one of 
the detection points is encountered, the SGSN will sus- 
pend normal processing and indicate the detectk>n point 
to the gprsSSF (service switching functton) or SIP UA 
214 depending on whether the event is to be reported 
with CAMEL or SIP The gprsSSF or the SIP UA 21 4 will 
detemiine the necessary action, and trigger the network 
events to the CSE 220 or the SIP AS 21 6, where appro- 
priate servk:e k>gk: is invoked and executed (FIG. 2). 
[0037] The PDP_context_establishment DP 820 indi- 
cates that an activate PDP context request has been 
received. PDP context establishment acknowledge- 
ment 824 indicates a create PDP context response is 
received from.the GGSN 210. PDP. context disconnec- 
tion 822 indk^ates a deactivate PDP context request and 
delete PDP context request are received. Change of po- 
sition 824 indicates a routing area update is received. 

Network Services 

[0038] According to one embodiment of the present 
invention, Push Portal, Presence, and Push Web Based 
Pre-paid Recharging are provided as services for net- 
works in the SGSN 208. Other services/applications can 
also be developed and deployed. 
[0039] There are two different ways a content can be 
accessed. Pull - the client directly requests the content. 
Push - the client signals its readiness to accept the con- 
tent, and the other party sends the content to the client 
without its direct request. 

Push Portal Service 

[0040] A portal provides mobile subscribers with an 
integrated and secure web based interface to other In- 
ternet contents such as infomnation. application, exper- 
tise, etc., which may be provided either by the network 
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operator itself, or by 3rd party content providers. In the 
wireless world, the visited network operator would like 
to serve as a portal, which serves as an entrance for the 
mobile subscriber to enter other sites on the Internet. 
The portal site provides free servk:es such as search 
engine, local news, local weather forecast, local traffic 
situation, local businesses and other local infonnatlon. 
Portal advertises the operator's Local Operator Initiated 
Servbes to the visited subscribers. Portal service is free, 
and the advertisement is the major way for the operator 
to make profit. An ordinary pull wireless portal can not 
fully satisfies the nehvork operator's needs, because it 
requires the mobile subscriber to explicitly browse to the 
URL of the portal site, or pull the contents from the portal 
site. A pull portal may be provkJed by 3rd party ASPs 
rather than by the network operator. The main difficulty 
for the visited subscribers is they very likely do not know 
the URL of the portal site, and therefore are not able to 
browse to the portal site even rf they do want to access 
the local information/service. 

[0041] For this reason, a push portal sen^ is pro- 
vided according to embodiments of the present inven- 
tion. A "push" service is a service that is not specifk^ally 
requested from the end user, but is directed to the end 
user's mobile statk>n by the network when the end user 
signals he is ready to communkrate. for example, when 
he powers on his mobile station. These services are in- 
itiated by the service provider and triggered by a network 
event. Providing the Push Portal servk^ Is based on free 
of charge servk^e given to subscribers and generation 
of the revenue stream coming from advertising local 
companies providing content delivery to the portal ap- 
plication. In a typical case, a network event triggers the 
service and a web page or af>plk:atk>n window is 
"pushed" to the subscriber's nrK>bile station. The sub- 
scriber then can make use of the web page or window 
free of charge. The pushed contents are delivered 
based on an operator owned PDP context, whk:h is free 
of charge to the mobile subscriber. The activation of an 
operator owned PDP context is requested either from 
the SGSN, or from another network entity such SIP AS. 
An operator owned PDP context has a Charging ID that 
indicates the operator, rather than the mobile subscrib- 
er, should pay for the packets transmitted, the connec- 
tion time, the OoS, etc., associated with that PDP con- 
text. Typically, the subscriber cannot use the operator 
owned PDP context for his chargeable services, be- 
cause no address bar is provided in the pushed window. 
[0042] Such operator owned contexts are typically 
free of charge to the subscriber, even when the sub- 
scriber is a pre-paid servkie subscriber As such, when 
the operator owned context is triggered, a special 
Charging ID is provided by the GGSN 2 1 0, or a Charging 
ID in a partk;ular range is provided, to ensure that the 
subscriber is not charged for the service. The home CSE 
220 does not charge when it sees the identification. 
[0043] The offering of the Push Portal service pro- 
vides to a wireless network Operator an additional pos- 
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sibilrty for generation of a revenue streanrt from roaming 
(and home) subscribers moving around a defined geo- 
graphical area, e.g. served by a singular SGSN. The 
network triggers the content delivery upon the mobile 
station powering on or changing of position (the mobile 
station enters or moves into an area served by another 
SGSN) without the mobile subscribers* explicit request. 
[0044] In order to trigger a '*push'* servk:e at DP Attach 
and/or other detection points, a SGSN Requested PDP 
Context Activation is provided. The network may further 
mark this SGSN requested PDP context as an operator 
owned PDP context in order that the services provided 
t>ased on that are free of charge for the nrwbile subscrib- 
er. FIG. 10 illustrates the SGSN Requested PDP Con- 
text activation. In step 502, the SGSN 208 sends a Re- 
quest PDP Context activation request to the mobile sta- 
tion 202. In step 504, the MS 202 undertakes the PDP 
context activation procedure described above. At DP At- 
tach, 9 the SGSN 208 decides the trigger of network 
events is needed, it invokes this procedure before it trig- 
gers the event to the SIP applk:ation server. The PDP 
address of the PDP context is the dynamic IP address 
the SIP applk:ation server 21 6 is to use to push contents 
to the rTK)bile station 202. 

[0045] The push portal service triggered at a subscrib- 
er's mobile station attachment to the GPRS network is 

further illustrated in FIG. 11. When the sut>scriber pow- 
ers on its mobile station 202, an Attach request 1150 is 
sent to the network. Once the SGSN 208 intercepts the 
request, it initiates Operator Owned PDP Context Acti- 
vation. As noted above, this PDP Context is owned by 
the network, and is free of charge to the mobile subscrib- 
er The SGSN 208 sends a SIP REGISTER request 
1 1 52 to the SIP Applk:ation Server (in the same manner 
as ft sends. a CAP request InitialDPGPRS to the CSE 
when using CAMEL). This SIP REGISTER request con- 
tains the information such as the PDP Context informa- 
tion for the newly activated Operator Owned PDP Con- 
text. Upon receiving the SIP REGISTER request, the 
SIP Applk:ation Server 216, which serves as a push ' 
originator, pushes a portal web page 1 154 to the mobile 
station. The automatk^alty triggered Push Portal service 
by the wireless core network provides a mechanism for 
a wireless network Operator to advertise the entire avail- 
able Local Operator Initiated Services and third party 
contents to the home and roaming subscribers. 
[0046] The contents being pushed by the Push Server 
include but are not limited to: (1) Portal servk^es (WAP 
or HTTP based), like the Portal solution previously de- 
scribed Advertisement; (2) Status of Presence; (3) Op- 
erator generated messages; and (4) Information about 
existing local operator services. 
[0047] Push Portal service ensures that mobile sub- 
scribers receive the content selection defined by the Op- 
erator, together with alt the corresponding links. Increas- 
ing access to the content provided via Push Portal trans- 
lates Into increasing revenue for the operator from the 
advertisement Industry Pushed operator message 



services open a channel for the operator to communi- 
cate with its mobile subscribers in real tirrie. The auto- 
matically pushed infonrnation does not require mobile 
subscribers to memorize specific URL information. In 
5 addition, innovative multimedia servk:es associated 
with Push Server help to reduce subscriber churn. 
[0048] Push Portal Servkre is a Local Operator Initiat- 
ed Service, and is offered free of charge for the sub- 
scribers. The local operator may even wish to reward 
the subscribers for receiving advertisements by offering 
discounts for regular subscription fee, or generating 
electronic coupons for advertised goods or services. 
[0049] However, there could still be some subscribers 
who prefer not to receive advertisement. For these sub- 
1^ scribers the local operator nrtay wish to provide the ca- 
pability to deactivate and reactivate the local operator's 
push portal servk:e. Here an application layer solution 
is described. 

[0050] A subscriber will receive the push portal the 
20 first tinr^ he powers his mobile statk>n on at a certain 
visited network, and will remain receiving it at the sub- 
sequent power on until he explcitfy deactivates the push 
portal service from his nK>bile station. In the web window 
of the pushed portal, there is a deactivation button. By 
^ clicking the button, the subscriber deactivates the push 
portal servk^es. The subscriber's IMSl or MSISDN will 
be recorded in the SIP Applcation Server 21 6. Next time 
when the sut>scriber powers his mobile statk>n on, the 
SIP Application Server21 6 checks his IMSl or MSISDN 
30 against the black list table. It does not push a portal page 
if a match is found. When the subscriber dk:ks the de- 
activation button from the pushed portal page, a reacti- 
vation bookmark Is inserted into his bookmarks, whk:h 
he can later use to reactivate the push portal service. 
35 The assumption is the whole tcx^l network shares the 
same SIP Applk:ation Server 21 6. 

Presence Service 

40 [0051 ] As noted above, a system according to emt>od- 
iments of the present invention implement "Presence" 
services. "Presence" refers to the status of a devk^ (de- 
vk:es) a person may use to which communfcation can 
be established. For example, It indicates whether a cel- 
45 lular phone Is switched on, or if a subscriber Is logged 
on to a PC, etc. Presence services refer to a class of 
services that make use of the Presence status informa- 
tion. For example, Instant Message is an individual serv- 
ice offering using Presence status information. Many 
50 other servces can be created on top of Presence status. 
[0052] Another closely related concept is "Availabili- 
ty." Availability refers to the personal preferences and 
policies an Individual or enterprise specifies for his/their 
communication services. Availability Information allows 
55 the mobile subscriber or networtc administrator to cus- 
tomize when and how to accept communication. 
[0053] On wireless networks, location information can 
be Incorporated with Presence as an attribute. There- 
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fore, in a broader sense» Presence status actually refers 
to Presence and Availability status as well as Location 
Information. 

[0054] Many services can be built based on presence/ 
availability/location information, such as Buddy List, Au- 5 
to Conference, Presence Based Directory (intelligent 
address book), etc. 

[0055] There could be different levels of presence. It 
could be a simple power on of mobile subscriber's mo- 
bile station, to an explicit message from the mobile sub- fo 
scriberto indicate his availability. Each level of presence 
represents the subscriber's availability/willingness to 
accept communication from a certain group. According 
to embodiments of the present invention* possible 
events to report the mobile subscriber's presence status '5 
include: 1) GPRS Attach event reported from the SGSN 
to indicate the mobile subscriber has powered on his 
mobile station; 2) GPRS PDP Context Activation event 
reported from the SGSN to indicate the mobile subscrib- 
er has an open channel to be contacted; 3) Various mes- 20 
sages sent explicitly from the mobile subscriber's de- 
vice, e.g., mobile station or PC or other, to indicate the 
subscriber's different level of availability/Willingness to 
be contacted; and 4) Further preserxre status can be es- 
tablished by CSCF (call state control function) regtstra- 2S 
tion (application layer registration) event reported from 
the serving CSCF in an IMS (IP Multinr^edia subsystem) 
network to indicate the mobile subscriber has an open 
channel to undertake a multimedia session. 
[0056] The presence status is stored in a centralized 30 
presence server in the home network regardless which 
event established the status. SIP SUBSRI BE/NOTIFY 
message may be used for another party to subscribe to 
a subscriber's presence status, and/or to be notified of 
the subscriber's presence status from the pr^ence . 35 
server. SIP REGISTER and other possible SIP messag- 
es are suitable to report a subscriber's presence status 
to the presence server 

[0057] FIG. 12 is an example of presence service 
where the presence status is established at the sub- ^ 
scriber's attachment to the GPRS network. The pres- 
ence server notifies another user of the presence status 
change, who previously subscribed to this infomnation. 
[0058] User B subscribes to User A*s presence status 
by SUBSCRIBE 1202 User A*s static IP address or his 
URI. The subscription is done by contacting User A's 
home presence server, which is an Application Server 
(may or may not be SIP enabled). It is assumed that 
User A was not online yet. Otherwise the Application 
Sender would send notFfk:ation message right away to 50 
User B. When User A powers on, the network (SGSN) 
intercepts the event and sends a SIP REGISTER 1204 
request to the SIP Application Server (visited presence 
server), which in turn forwards the information to User 
A's home presence server 1 206. The subscription list is 55 
checked there and a notification message 1210 Is sent 
to User B. An Instant Message 1 208 from User B to User 
A follows. User B may choose to use other means to 



contact User A, such as SMS. 



Push Web-Based Pre-Paki Service 



[0059] As noted above, one aspect of an embodiment 
of the present invention is push web-based pre-paid re- 
charging servce. Pre-paid is one of the most successful 
services in today's wireless market. Typical current Pre- 
paid servk:es are based on the CAMEL protocol. CAM- 
EL was originally designed for circuit switching net- 
works, and has since been adapted to serve packet 
switching network as well. However, the Pre-paid re- 
charging is usually undertaken via a mobile station, or 
a landline phone. t>y calling an IVR (Interactive Vok:e 
Response) system. The pre-paid recharging can also 
be undertaken via a PC by accessing a web interface. 
Both IVR and the web server should interface with the 
Pre-paid account database. In such systems. Pre-paid 
recharging can be done on a web interface directly from 
a mobile statk>n, which requires an explk:rt browsing to 
the recharging website. However, in some cases, a sub- 
scriber with account balance bek>w a certain threshold 
would not be allowed to use wireless resource any more, 
nnaking it impossible for him to recharge his account this 
way. 

[0060] FIG. 13 illustrates a SIP Applk:ation Server en- 
abled Pre-paW Recharging service whfch overcomes 
these and other problenns. This service applies to home 
subscribers only. Tbe Pre-paki subscrik>er is notified of 
his low balance when powerirtg on his mobile statk>n 
and attachlrtg rl to the GPRS networic The notifk:atk>n 
is delivered in a recharging window 1 302 where the sub- 
scriber can recharge his account interactively. This re- 
charging service is using an operator owned PDP Con- 
text, and is free of charge to the subscriber. This guar- 
antees the subscriber an opportunity to recharge his ac- 
count even If he has already run out of his balance in 
his account. 

[0061 ] The physical Pre-paid account database does 
not have to be located on the SIP Applk:ation Server 
21 6. The SIP Applk:ation Server21 6 simply pushes the 

recharging page, admiriistered by the web server co-lo- 
cated with the Pre-paid recharging server, to the sub- 
scriber's mobile station 202. SIP Applk:ation Sen/er 21 6 
should be allowed to access the subscriber's account in 
the existing Pre-paid account database, in order to 
check the subscriber's account balance. 
[0062] When the Pre-paid subscriber powers on his 
mobile station and thus attaches to the GPRS network, 
the networi< (SGSN) 208 intercepts this attach event. It 
sends a SIP REGISTER request 1303 to the SIP Appli- 
cation Server 216, which will then cafculate the sub- 
scriber's account balance 1301 . If the account balance 
is below a threshold, the SIP Application Server 21 6 will 
pushes a Pre-paid recharging web page 1 302 to the mo- 
bile station 202. It is assumed that the operator owned 
PDP Context needed for the recharging has already ac- 
tivated (with push portal service). The Web based Pre- 
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paid service provides the possibility to recharge sub- 
scriber's account utilizing interactive Web page. The 
subscriber is able to recharge his account at the begm- 
ning or during the active session. In the event that nnid- 
call the subscriber account balance decreases to the al- s 
located threshold, the subscriber is requested to re- 
charge his account on the Web page pushed to his mo- 
bile station by the SIP AS 21 6. 

SGSN and SIP Protocol Stack io 

[0063] As noted above, according to an implementa- 
tion of the invention, a SIP user agent 214 is provided 
in the SGSN 208. In operation, when an Attach request 
fronn the mobile station is received, the SIP user agent is 
214 sends a SIP Register request to the SIP AS 216. 
The Register request contains the IP address of the mo- 
bile station. The SIP AS 216 may then push content to 
the mobile station. When the packet arrives at the 
GGSN 21 0. it delivers the content to the mobile station. 20 
In case the destination IP address is a permanent IP 
address (static PDP address) and the PDP Context Is 
not activated, the GGSN 210 has to initiate a Network 
Requested PDP activation first. On the other hand, if the 
I P address is a temporary IP address (dynamk: PDP ad- 25 
dress), the corresponding PDP context must have al- 
ready been activated, either requested by the mobile 
station, or by the SGSN. 

[0064] As shown in FIG. 1 4, in one embodiment of the 
present invention, the SGSN 208 implements a Gb/lu 30 
handler 1402, a Mobility Management functk>n (MM) 

1404, a gprsSSF 1406, a Session Management function 
(SM) 1408, the SIP UA 214, and the SIP Protocol stack 
3000, as will be explained in greater detail below. 
[0065] In what follows, a first embodiment of the .35 
present invention employing static PDP addressing will 
be described, followed t>y a second embodiment of the 
present invention employing dynamk; PDP addressing. 

Static PDP Address 40 

[0066] The Gb/lu handler 1402 may be implemented 
on the Mobility Management unit 1404 and handles the 
GPRS Attach process. When the Attach Is accepted, but 
the ATTACH Accept message is not yet sent (the Attach ^5 
process is successful, but is not yet completed), Gb/lu- 
Handler 1402 checks if a SGSN configuration flag 
SIP_AS is set. (f the flag is not set, Gb/lu-Handler 1402 
proceeds to complete the Attach process in a nomnal 
way as defined by CAMEL. Otherwise, it starts to pre- so 
pare extra parameters for an ATTACH Accept message 
by scanning the subscriber profile. It returns to the At- 
tach process If no static PDP Address Is found from the 
subscriber profile. Othenwise, It sets a parameter PDP 
Address with the static PDP address it has found. S5 
[0067] The message ATTACH Accept that Is to be 
sent from the Gb/lu-Handler 1402 to the mobile station 
via MM 1404 may be extended to contain the extra pa- 



rameters IMSI (or P-TMSI). MSISDN, RAI and PDP Ad- 
dress. 

[0068] The Gb/lu-Handler 1402 sends the ATTACH 
Accept message to the mobile station via MM 1404. be- 
fore ft proceeds to complete the Attach process. 
[0069] Upon receiving the ATTACH Accepted mes- 
sage from the Gb/lu-Handler 1402, MM 1404 examines 
if the extra parameters IMSI, MSISDN, RAI are PDP Ad- 
dress are contained in the message. If not, it proceeds 
normally and forwards the message to the mobile sta- 
tion. Otherwise, it extracts and strips off these parame- 
ters from the ATTACH Accepted message before for- 
warding it to the mobile station 202. 
[0070] The MM 1404 then prepares the new SGSN 
internal message Start SIP UA with the received param- 
eters IMSI. MSISDN, RAI, and PDP Address as the pa- 
rameters of the new message. It then sends the Start 
SIP UA message to the SIP UA 214. 
IPOTI] To allow communication between the SGSN 
208 and the SIP AS 216, a functional entity SIP UA 214 
is added on the SGSN as shown in FIG 14. The main 
function of the SIP UA 214 is to report the network 
events to the SIP AS 216 so that services can be trig- 
gered, and process the responses sent back from the 
SIP AS 21 6. Upon receiving the Start SIP U A message 
from MM 1404, the SIP UA 214 extracts the MSISDN, 
RAI and PDP Address parameters from the message 
and prepares the SIP REGISTER request. The SIP UA 
214 then sends the SIP REGISTER request with IMSI. 
MSISDN, RAI and PDP Address pa ranneters embedded 
in the message body to the SIP Applk:ation Server 216. 
The SIP UA 21 4 waits for an OK 200 response from the 
SIP AS 216 before it closes the dialogue. 
[0072] Although the SIP AS 21 6 is located in the same 
network as the SGSN 208,.in certain embodiments, they 
are not connected via standard Gn interface. Instead, 
the SIP interface between the SGSN and the SIP /\S 
216 is placed right on top of UDP/IP. The SIP UA 214 
first strips off the GTP layer before it sends the SIP re- 
quest to the SIP AS 216. This interface is thus referred 
to as Gn* interface. 

[0073] As noted above, according to an embodiment 
of the invention, a SGSN Internal message Start SI P UA 
is defined and contains the following parameters: IMSI; 
MSISDN; RAI; and PDP Address. The message Is sent 
from MM 1404 to the SIP UA 214. 

Dynamic PDP Addressing 

[0074] IPv4 supports only a limited address space, 
and as a result IP addresses are a very valuable re- 
source for mobile operators. Usually a mobile station Is 
not assigned a static PDP address (a permanent IP ad- 
dress) as described above. Instead, an IP address is 
dynamically assigned (dynamic PDP Address) when a 
mobile subscriber attaches his mobile station to the 
wireless network and activates a PDP Context. The Op- 
erator Owned PDP Context Activation described herein 
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may be used to accommodate dynamic PDP address- 
ing. Operator Owned PDP Context Activation does not 
rely on static PDP address because it is not triggered at 
the incoming PDU (Packet Data Unit), which is routed 
to the visited network according to the static PDP ad- 5 
dress contained in the packet header. The Operator 
Owned PDP Context Activation is requested by the SG- 
SN at some triggering event, e.g., ATTACH event. When 
the Attach request is accepted, the SGSN reports this 
event by sending a new internal message to the SI P UA io 
214. The SIP UA 214 starts the Operator Owned PDP 
Context Acthfatk>n procedure. This PDP Context is only 
to be used with the services defined by the operator, and 
is free of charge for a mobile subscriber. The SGSN in- 
tercepts the dynamic PDP Address the GGSN 210 as- '5 
signs to the rTK)bile station, which is a temporary IP ad- 
dress, and sends the address to the SIP UA 214. The 
SIP UA 21 4 then sends a SIP REGISTER request to the 
SIP AS 21 6, containing the dynamk: PDP Address in its 
body. With this PDP Address, the SIP AS 21 6 can push 2o 
contents to the mobile station depending on the service 
logic. 

[0075] The behavior of the Gb/lu handler 1402 in the 
dynamic case is generally similar to that in the static 
case, except Gb/lu-Handler 1402 will continue to proc- 
ess SIP AS 21 6 request even if no static PDP Address 
is found. In this case Gtwlu-Handler set PDP Address to 
zero to indcate dynamk: PDP Address is alk>wed. 
[0076] Upon recehfing Start SIP UA request, SIP UA 
21 4 extracts all the parameters from the message. SIP 30 
UA 214 then sends a PDU Notif cation Request to Ses- 
sion Management (SM) 1408, containing parameters 
IMSI, PDP Type, PDP Address and APN. IMSI and PDP 
Address are received from Start SIP UA request, PDP 
Type is set to IP. APN is provkJed by SIP UA 214, and 35 
it maps to a GGSN 21 0 in the local wireless network. 
The purpose for this message is to convey the Operator 
Owned PDP Context Activation. The SIP UA 214 will 
store the parameter MSISDN and RAI locally. The SIP 
U A 21 4 then waits for PDU Notifk:ation Response mes- 
sage from SM 1408. 

[0077] Once SIP UA 214 has received PDU Notifica- 
tion Response from SM 1408, the dialogue between SM 
1408 and SIP UA 214 is closed. SIP UA 214 extracts 
the PDP Address parameter from the PDU Notification 
Response message and prepares for a SIP REGISTER 
request. SIP UA 214 then sends the SIP REGISTER re- 
quest to SIP Application Server216, with MSISDN, RAI 
and PDP Address parameters embedded in the mes- 
sage body. The header fields of the SIP message are 50 
set. The SIP UA 214 strips off the GTP layer before it 
sends the SIP request to the SIP AS 216. Then SIP UA 
21 4 waits for the OK 200 response from the SIP AS 2 1 6 
before it closes the dialogue. 

55 

Session Management 

[0078] The Session Management (SM) unit 1 408 han- 



dles the session related functionality such as PDP Con- 
text handling, subscription check, context table man- 
agement, etc. The Session Management 1 408 handles 
MS Requested PDP Context Activation and Networi( 
Requested PDP Context Activation. SM 1408 also han- 
dles the Operator Owned PDP Context Activation re- 
quested from the SGSN according to the present inven- 
tion. To do so, SM 1408 has to differentiate these three 
different types of PDP Context Activation. For the Net- 
work Requested PDP Context Activation, SM receives 
the PDU Notifk^ation Request from the GGSN 21 0; while 
for the Operator Owned PDP Context Activation, SM 
1408 receives the PDU Notification Request from the 
SIP UA 214. An Internal SGSN flag PDPContextType is 
introduced with valid values to be MS_Requested (null), 
Network^Requested or Operator_Owned. Upon receiv- 
ing the PDU Notifx^tion Request, the SM 1408 checks 
the message source. If the message is from the GGSN 
210, SM 1408 returns a PDU Notificatk>n Response to 
the GGSN 210, and sets the PDPContextType flag to 
Network_Requested. On the other hand, if the nnessage 
is from the SIP U A 21 4, the SM 1 408 will defer the PDU 
Notifk^ation Response to the SIP UA 21 4. It sets the PD- 
PContextType flag to Operator_Owned. SM 1408 sends 
a Request PDP Context Actrvatk>n message to the mo- 
bile statk>n via MM, with parameters PDP Type, PDP 
Address and APN that it has received from the PDU No- 
tifkratk>n Request. A standard (mobile statk>n Request- 
ed) PDP Context Acth^atk>n then folkyws. 
[0079] SM 1408 sends a Create PDP Context Re- 
quest to the GGSN 210 that contains a parameter 
Charging Characteristk:s. Since the purpose of the Op- 
erator Owned PDP Context Activation is to create a PDP 
Context that is free of charge for the subscriber, there- 
fore SM 1408 checks the flag PDPContextType again. 
If it is set to Operator_Owned, SM sets Charging Char- 
acteristk:s to Tree of Charge*, and sets the indication to 
be 'default profile determined by the SGSN*. 
[0080] In the standard MS Requested PDP Context 
Activation, SM 1408 receives the dynamic PDP Address 
from the GGSN 210 in the Create PDP Context Re- 
sponse message, in case the mobile station does not 
have a static PDP Address. Therefore SM 1408 has the 
knowledge of the PDP Address dynamically assigned 
by the GGSN 210. Upon completion of the standard 
PDP Context Activation procedure, SM 1408 sends an 
Activate PDP Context Accept message to the mobile 
station. SM 1408 checks PDPContextType flag. If it is 
set to Operator_Owned, SM 1408 sends the previous 
defen-ed PDU Notlfk:atlon Response message to the 
SIP UA 214. and then closes the dialogue behveen 
these two entities. The PDU Notification Response mes- 
sage Is extended to contain the extra parameter PDP 
Address. SM 1408 communk:ates with both the SIP UA 
214 and the GGSN 210 in the Operator Owned PDP 
Context Activation procedure. SM has to analyze the 
destination of each message for each destination. The 
internal message Start SIP UA in the static case is ex- 
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tended to contain extra parameters PDP Type and APN. 
[0081] In another embodiment, Operated Owned 
PDP Context Activation is not requested from the SGSN 
208, but instead it is requested from the SIP AS 216. 
When the Start SIP UA message Is received, the SIP 5 
UA 214 sends the SIP REGISTER request to the SIP 
AS 21 6. SIP AS 21 6 then sends a SIP request, e.g., SIP 
INFO to query for the IP address. Upon receiving this 
SIP request, SIP UA 214 sends a PDU Notification Re- 
quest to SM to start Operator Owned PDP Context Ac- io 
tlvation. SIP UA 214 returns aSIP INFO message to the 
SIP AS 21 6 canrying a PDP Address it receives from SM 
1408. 

.Signaling Flow 

[0082] Turning now to FIG. 15, a signaling diagram of 
operation of an embodiment of the Invention as it re- 
ceives pushed content, such as a Web page, is shown. 
In particular, FIG. 1 5 illustrates the signaling upon a mo- 2t> 
bile station 202 powering on and recerving a pushed 
content from the network. As shown, in 1602, the mobile 
station 202 undertakes the Attach at the power on by 
sending Attach to the SGSN 208. The Gb/lu handler 
1402 sends the Attach_Accept message to the MM 25 
1404, in step 1 604. The MM responses with Attach Ac- 
cept 1606 to Indicate the attach process is successful. 
It also issues the internal Start_SIP_UA command to the 
SIP UA 214, in step 1608. The SIP UA 214 responds 
with a PDU notif k:atk>n request, in step 1 61 0. The SGSN 3o 
208 starts to perform a SGSN Requested PDP Context 
Activation by sending the mobile station 202 a Request 
PDP Context Activation 1612, as descn'bed above, con- 
taining an empty PDP address to lndk:ate dynamic PDP 
address is allowed. Between the mobile station 202 and 35 
the GGSN 210, a PDP Context Activation Procedure 
1614 is perfonned, as described above. In step 1618, 
the session manager 1408 sends the PDU Notifk:atlon 
Response to the SIP UA 214. The GGSN 210 further 
assigns a dynamic PDP address to the PDP context for ^ 
the mobile station 202. The information is also intercept- 
ed by the SGSN 208, The SGSN 208 then triggers the 
Attach event to the SIP AS 216 via the SIP UA 214 with 
a SI P REGISTER request 1 620, containing the dynamic 
PDP address assigned by the GGSN 21 0. The SIP AS ^5 
216 responds to the SGSN 208 via the SIP UA 214 with 
a SIP 200 OK response 1622 to indicate the SIP REG- 
ISTER request 1620 is property processed in the SIP 
AS 216. The SIP AS 216 then in step 1624 pushes an 
appropriate content, decided by its internal sen/ice logk:, 50 
to the destination Identified by the IP address, whfch is 
the dynamic PDP address it received from the SGSN 
208 in step 1 620. The content is delivered to the GGSN 
21 0. forwarded to the SGSN 208, and finally reaches Its 
destination mobile station 202. 
[0083] FIG. 16 is a diagram illustrating message flow 
for a sample Presence Sen/ice followed by Instant Mes- 
saging. In the example shown, User B 202b subscribes 



to the presence status of User A 202a at the SIP Appli- 
cation Server 21 6, which serves as the Presence Serv- 
er When the mobile station User A powers on, the SG- 
SN 208 will register to the SIP AS 216 on behalf of the 
User A. The SIP AS 216 will notify User B of User A's 
presence. 

[0084] At step 1702, the User B sends a SIP Sub- 
scribe request to the SIP AS 216 to subscribe to the 
presence status of User A. At step 1 704, User A powers 
on his mobile station and sends an Attach request tothe 
SGSN 208. At step 1 706, the Gb/lu handler 1402 sends 
the Attach_Accept message to the MM 1404. The MM 
1404 checks the SGSN internal SI P_AS flag and scans 
the subscnt>er profile and sends the Attach accept mes> 
sage to the User A at step 1708. At step 1710, a 
Start_SIP_UA message is sent to the SIP UA 214. At 
step 1712, a SIP Register message is sent to the SIP 
AS 216 that the MS A is successfully attached. At step 
1714» the SIP AS 216 responds with an OK message. 
At step 1716, the SIP AS 216 checks if anyone is to be 
notified of the presence of MS A, and sends a notify 
message to User B. Finally, at step 1 71 8, User B starts 
an Instant Message Application, which triggers a Net- 
work Requested PDP context activation. In this case Us- 
er A is assumed to have subscribed to a static PDP ad- 
dress. 

[0085) The invention described in the above detailed 
description is not intended to be limited to the specif k; 
fonm set forth herein, but Is intended to cover such al- 
ternatives, modifications and equivalents as can rea- 
sonably be iriduded within the scope of the appended 
claims. 



Claims 

1 . A telecommunk:atk>ns system, characterized ftyy: 

a Serving GPRS support node (SGSN) (208) 
adapted to interface to a mobile station (202); 
and 

a gateway GPRS support node (GGSN) (210) 
adapted to couple to a packet network (212); 

wherein said SSGN includes a Session Initi- 
ation Protocol (SIP) user agent (214) for interfacing 
to a SIP applk;ation server (216), to provkJe multi- 
media services to said mobile station. 

2. A telecommunications system in accordance with 
claim 1 , said SGSN (208) adapted to initiate a PDP 
context activation procedure if said SGSN (208) de- 
tenmines, or an other network function/entity in- 
structs the SGSN (208). that such a PDP context 
activation Is needed to support further services. 

3. A telecommunications system in accordance with 
claim 2, said PDP activation procedure adapted to 
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be implemented at DP attach or other detection 
points. 

4. A telecommunications method, characterized by: 

processing a detection point attach when the 
normal GPRS attach process is successful but 
is not completed; 

an SGSN (208) requesting PDP context activa- 
tion; and 

triggering an SIP request. 

5. A GPRS telecommunications system, character- 
ized by: 

a Serving GPRS support node (SGSN (208)) 
adapted to interface to a mobile station, where- 
in said SGSN (208) includes a Session Initia- 
tion Protocol (SIP) user agent (214); 
a gateway GPRS support node (GGSN (210)) 
adapted to couple to a packet network; and 
a SIP application server (216), said SIP user 
agent (214) and said SIP application server 
(216) adapted to provide multimedia servk^es 
to said mobile station. 

6. A GPRS telecommunications system In accordance 
with claim 5, said SGSN (208) and said SIP appli- 
catbn server (21 6) adapted to implement an oper- 
ator owned PDP context activatk>n. 
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providing a gateway GPRS support node 
(GGSN (210)) adapted to couple to a packet 
network (212); and 

providing a SIP application server (216), said 
SIP user agent (214) and said SIP application 
server (216) adapted to provide multimedia 
services to said mobile station (202). 

12. A method in accordance with claim 11 , said SGSN 
(208) and said SIP application server (21 6) adapted 
to implement an operator owned PDP context acti- 
vation. 

13. A method in accordance with claim 12» said opera- 
tor owned PDP activation procedure adapted to be 
implemented at DP attach or other detection points. 

14. A method in accordance with claim 13, said SGSN 
(208) and saki SIP applk:ation server (21 6) adapted 
to implement push servk:es. 

15. A method in accordance with claim 13, said SGSN 
(208) and said SIP application server (21 6) adapted 
to implement presence status. 

16. A method in accordance with claim 13, said SGSN 
(208) and sakl SIP applk:ation server (21 6) adapted 
to implement push pre-paid recharging service 



30 1 7. A method in a GPRS network, characterized by: 



7. A GPRS telecommunications system in accordance 
with claim 6, said operator owned PDP activation 
procedure adapted to be implemented at DP attach 
or other detection points. 

8. A GPRS telecommunk:atk>ns system in accordance 
with claim 7. said SGSN (208) and said SIP appli- 
cation server (216) adapted to implenr>ent push 
services. 

9. A GPRS telecommunkiations system in accordance 
with claim 7, said SGSN (208) and said SIP appli- 
cation server (21 6) adapted to implement presence 
status. 



requesting a DP attach from a mobile statk>n to 

an SGSN (208); 

requesting a PDP context activation from said 
3S SGSN (208) to said mobile station; 

performing a PDP context activatk>n in re- 
sponse to sakl requesting; and 
pushing content to said nriobile station. 

^ 1 8. A method in accordance with claim 1 7, said content 
characterized by one or more Web pages. 

19. A method in accordance with daim 1 8, further char- 
acterized by implementing push pre-paid recharg- 
45 ing service. 



10. A GPRS telecommunkrations system in accordance 
with claim 7. said SGSN (208) and said SIP appli- 
cation server (21 6) adapted to implement push pre- 
paid recharging service. ^ 

11. A method, characterized by: 

providing a Serving GPRS support node (SG- 
SN (208)) adapted to interface to a mobile sta- 55 
tion (202), wherein said SGSN (208) includes 
a Session Initiation Protocol (SIP) user agent 
(214); 
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